Structure of the TOGAF Document
The structure of the TOGAF documentation reflects the structure and content of an architecture capability within an
enterprise, as shown in Structure
of the TOGAF Document .
Figure: Structure of the TOGAF Document
There are seven main parts to the TOGAF document:
-
PART I
-
(Introduction) This part provides a high-level introduction to the key concepts of enterprise architecture and in
particular the TOGAF approach. It contains the definitions of terms used throughout TOGAF and release notes
detailing the changes between this version and the previous version of TOGAF.
-
PART II
-
(Architecture Development Method) This part is the core of TOGAF. It describes the TOGAF Architecture Development
Method (ADM) - a step-by-step approach to developing an enterprise architecture.
-
PART III
-
(ADM Guidelines and Techniques) This part contains a collection of guidelines and techniques available for use in
applying TOGAF and the TOGAF ADM.
-
PART IV
-
(Architecture Content Framework) This part describes the TOGAF content framework, including a structured metamodel
for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical
architecture deliverables.
-
PART V
-
(Enterprise Continuum & Tools) This part discusses appropriate taxonomies and tools to categorize and store the
outputs of architecture activity within an enterprise.
-
PART VI
-
(TOGAF Reference Models) This part provides a selection of architectural reference models, which includes the TOGAF
Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM).
-
PART VII
-
(Architecture Capability Framework) This part discusses the organization, processes, skills, roles, and
responsibilities required to establish and operate an architecture function within an enterprise.
The intention of dividing the TOGAF specification into these independent parts is to allow for different areas of
specialization to be considered in detail and potentially addressed in isolation. Although all parts work together as a
whole, it is also feasible to select particular parts for adoption whilst excluding others. For example, an
organization may wish to adopt the ADM process, but elect not to use any of the materials relating to architecture
capability.
As an open framework, such use is encouraged, particularly in the following situations:
-
Organizations that are new to TOGAF and wish to incrementally adopt TOGAF concepts are expected to focus on
particular parts of the specification for initial adoption, with other areas tabled for later consideration.
-
Organizations that have already deployed architecture frameworks may choose to merge these frameworks with aspects
of the TOGAF specification.
Executive Overview
According to The Open Group Business Executive's Guide to IT Architecture:1
"An effective enterprise architecture is critical to business survival and success and is the indispensable means to
achieving competitive advantage through IT."
This section provides an executive overview of enterprise architecture, the basic concepts of what it is (not just
another name for IT Architecture), and why it is needed. It provides a summary of the benefits of establishing an
enterprise architecture and adopting TOGAF to achieve that.
What is an enterprise? What is enterprise architecture?
TOGAF defines "enterprise" as any collection of organizations that has a common set of goals. For example, an
enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a
chain of geographically distant organizations linked together by common ownership.
The term "enterprise" in the context of "enterprise architecture" can be used to denote both an entire enterprise -
encompassing all of its information and technology services, processes, and infrastructure - and a specific domain
within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within
the enterprise.
Confusion often arises from the evolving nature of the term "enterprise". An extended enterprise nowadays frequently
includes partners, suppliers, and customers. If the goal is to integrate an extended enterprise, then the enterprise
comprises the partners, suppliers, and customers, as well as internal business units.
The business operating model concept is useful to determine the nature and scope of the enterprise architecture within
an organization. Large corporations and government agencies may comprise multiple enterprises, and may develop and
maintain a number of independent enterprise architectures to address each one. However, there is often much in common
about the information systems in each enterprise, and there is usually great potential for gain in the use of a common
architecture framework. For example, a common framework can provide a basis for the development of an Architecture
Repository for the integration and re-use of models, designs, and baseline data.
Why do I need an enterprise architecture?
The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes
(both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery
of the business strategy.
Today's CEOs know that the effective management and exploitation of information through IT is a key factor to business
success, and an indispensable means to achieving competitive advantage. An enterprise architecture addresses this need,
by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the
business environment.
Furthermore, a good enterprise architecture enables you to achieve the right balance between IT efficiency and business
innovation. It allows individual business units to innovate safely in their pursuit of competitive advantage. At the
same time, it ensures the needs of the organization for an integrated IT strategy are met, permitting the closest
possible synergy across the extended enterprise.
The advantages that result from a good enterprise architecture bring important business benefits, which are clearly
visible in the net profit or loss of a company or organization:
-
A more efficient IT operation:
-
Lower software development, support, and maintenance costs
-
Increased portability of applications
-
Improved interoperability and easier system and network management
-
Improved ability to address critical enterprise-wide issues like security
-
Easier upgrade and exchange of system components
-
Better return on existing investment, reduced risk for future investment:
-
Reduced complexity in IT infrastructure
-
Maximum return on investment in existing IT infrastructure
-
The flexibility to make, buy, or out-source IT solutions
-
Reduced risk overall in new investment, and the costs of IT ownership
-
Faster, simpler, and cheaper procurement:
-
Buying decisions are simpler, because the information governing procurement is readily available in a
coherent plan.
-
The procurement process is faster - maximizing procurement speed and flexibility without sacrificing
architectural coherence.
-
The ability to procure heterogeneous, multi-vendor open systems.
What specifically would prompt me to develop an enterprise
architecture?
Typically, an enterprise architecture is developed because key people have concerns that need to be addressed by the IT
systems within the organization. Such people are commonly referred to as the "stakeholders" in the system. The role of
the architect is to address these concerns, by identifying and refining the requirements that the stakeholders have,
developing views of the architecture that show how the concerns and the requirements are going to be addressed, and by
showing the trade-offs that are going to be made in reconciling the potentially conflicting concerns of different
stakeholders.
Without the enterprise architecture, it is highly unlikely that all the concerns and requirements will be considered
and met.
What is an architecture framework?
An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad
range of different architectures. It should describe a method for designing a target state of the enterprise in terms
of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and
provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be
used to implement the building blocks.
Why do I need TOGAF as a framework for enterprise architecture?
TOGAF has been developed through the collaborative efforts of 300 Architecture Forum member companies from some of the
world's leading IT customers and vendors and represents best practice in architecture development. Using TOGAF as the
architecture framework will allow architectures to be developed that are consistent, reflect the needs of stakeholders,
employ best practice, and give due consideration both to current requirements and to the likely future needs of the
business.
Architecture design is a technically complex process, and the design of heterogeneous, multi-vendor architectures is
particularly complex. TOGAF plays an important role in helping to "de-mystify" and de-risk the architecture development
process. TOGAF provides a platform for adding value, and enables users to build genuinely open systems-based solutions
to address their business issues and needs.
Who would benefit from using TOGAF?
Any organization undertaking, or planning to undertake, the design and implementation of an enterprise architecture for
the support of mission-critical business applications will benefit from use of TOGAF.
Organizations seeking Boundaryless Information Flow can use TOGAF to define and implement the structures and processes
to enable access to integrated information within and between enterprises.
Organizations that design and implement enterprise architectures using TOGAF are assured of a design and a procurement
specification that can facilitate an open systems implementation, thus enabling the benefits of open systems with
reduced risk.
|